The approaches described in this section could be pursued, but are not necessarily approaches that have been previously conceived or pursued. Therefore, unless otherwise indicated herein, the approaches described in this section are not prior art to the claims in this application and are not admitted to be prior art by inclusion in this section.
In many applications of encryption and/or authentication, the need to store cryptographic keys, and to fetch the appropriate key to process a particular message, is a performance bottleneck. In particular, when a network device receives an encrypted and/or authenticated message, it cannot process that message until it fetches the appropriate key from memory.
Authenticated encryption refers to a cryptographic transform which, in addition to providing confidentiality for the plaintext that is encrypted, provides a way to check its integrity and authenticity. For example, the combination of AES-CBC and HMAC-SHA1 are often combined to create an authenticated encryption method. Alternately, a dedicated Authenticated Encryption with Associated Data (AEAD) algorithm, such as Advanced Encryption Standard Galois/Counter Mode (AES-GCM) can be used.
AEAD adds the ability to check the integrity and authenticity of some Associated Data (AD), also called “additional authenticated data”, which is not encrypted. For example, when AEAD is used to protect packets in a network protocol, the headers (which typically need to be left unencrypted) are considered associated data and comprise the AD input. When AEAD is used in Encapsulating Security Payload (ESP), the ESP Security Parameters Index (SPI) and Sequence Number fields are input as AD.
In general, an AEAD operation takes as input a secret key K, an associated data element A, a nonce N, and a plaintext message P, and returns a ciphertext message C. The decryption operation takes as input the secret key K, the associated data element A, the nonce N, and the ciphertext message C, and returns the plaintext message P, or returns an indication that there was an authentication failure. The nonce is selected by the encrypter, may be distinct for each distinct packet, is sent with the message, and is used by the decrypter. In many security protocols, such as AES-GCM-ESP, the nonce is carried in an Initialization Vector (IV). Examplary AEAD operations may be written symbolically as: encrypt: K, A, N, P→C; decrypt: K, A, N, C→P or FAIL. An example of an AEAD system is described in IETF RFC 5116, “An Interface and Algorithms for Authenticated Encryption.”
When AEAD is used, the encrypting device uses certain unencrypted information (for example, the IV or the nonce) to encrypt the packet. This information is included in the packet by the encrypting device, so that the decrypting device has the all of the data that it needs to decrypt the packet. The decrypting device needs the same data in order to properly decrypt the packet.